The following description relates generally to the use of peripheral devices with software applications. More specifically, the following description relates to the use of device specific information and resources with such software 1applications.
The Universal Serial Bus (USB) is a cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible peripheral devices. The attached peripheral devices share USB bandwidth through a host-scheduled, token-based protocol. The bus allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation.
The USB is defined by a specification that is approved by a committee of industry representatives. The specification covers all aspects of USB operation, including electrical, mechanical, and communications characteristics. To be called a USB device, a peripheral must conform to this very exacting specification.
USB device information is typically stored in so-called xe2x80x9cdescriptorsxe2x80x9d or request codesxe2x80x94data structures formatted as specified by the USB specification. Descriptors are used in a USB system to define xe2x80x9cdevice requestsxe2x80x9d from a host to a peripheral device. A device request is a data structure that is conveyed in a xe2x80x9ccontrol transferxe2x80x9d from the host to the peripheral device. A control transfer contains the following fields:
bmRequestTypexe2x80x94a mask field indicating (a) the direction of data transfer in a subsequent phase of the control transfer; (b) a request type (standard, class, vendor, or reserved); and (c) a recipient (device, interface, endpoint, or other). The primary types of requests specified in the xe2x80x9crequest typexe2x80x9d field are the xe2x80x9cstandardxe2x80x9d and xe2x80x9cvendorxe2x80x9d types, which will be discussed below.
bRequestxe2x80x94a request code indicating one of a plurality of different commands to which the device is responsive.
wValuexe2x80x94a field that varies according to the request specified by bRequest.
wIndexxe2x80x94a field that varies according to request; typically used to pass an index or offset as part of the specified request.
wLengthxe2x80x94number of bytes to transfer if there is a subsequent data stage.
All USB devices are supposed to support and respond to xe2x80x9cstandardxe2x80x9d requestsxe2x80x94referred to herein as xe2x80x9cUSB-specificxe2x80x9d requests. In USB-specific requests, the request type portion of the bmRequestType field contains a predefined value indicative of the xe2x80x9cstandardxe2x80x9d request type.
Each different USB-specific request has a pre-assigned USB-specific request code, defined in the USB specification. This is the value used in the bRequest field of the device request, to differentiate between different USB-specific requests. For each USB-specific request code, the USB specification sets forth the meanings of wValue and wIndex, as well as the format of any returned data.
USB devices can optionally support xe2x80x9cvendorxe2x80x9d requestsxe2x80x94referred to herein as xe2x80x9cdevice-specificxe2x80x9d requests. In a device-specific request, the request type portion of the bmRequestType field contains a predefined value to indicate a xe2x80x9cvendorxe2x80x9d request type. In the case of device-specific requests, the USB specification does not assign request codes, define the meanings of wValue and wIndex, or define the format of returned data. Rather, each device has nearly complete control over the meaning, functionality, and data format of device-specific requests. Specifically, the device can define its own requests and assign device-specified request codes to them. This allows devices to implement their own device requests for use by host computers, and provides tremendous flexibility for manufacturers of peripherals.
The inventors have discovered a need for a similar feature that would benefit various hosts, application programs, host operating systems hardware manufacturers (OEMs), and Independent Hardware Vendors (IHVs). Specifically, designers of application programs and operating systems would value the opportunity to define their own device requests (and the associated responses), and to have such requests supported in a uniform way by compatible peripherals. Moreover, OEMs and IHVs would value the ability to supply additional USB device specific information to the hosts, application programs and host operating systems in response to such device requests. However, the different request types supported in the bmRequestType field of a USB device request do not include a xe2x80x9chostxe2x80x9d type of request.
As an example of this need for a host type of request, consider that the USB Device Working Group (DWG) has defined a set of standards that describe different types of USB devices. For each of these standards, the DWG has created a respective class specification that specifies static predetermined class and subclass numbers that correspond to the class specification. These specifications are designed such that to be in compliance with a particular class specification, an operating system must include only a single default, or xe2x80x9cgenericxe2x80x9d device driver to control a USB device that is configured according to the particular class specification.
When a USB device is installed onto a system, the device indicates that it was created according to a particular DWG class specification by listing predefined class and subclass codes that correspond to the DWG specification. These predefined codes can be used by an operating system to load a single generic device driver to control the device.
However, it is often the case that a vendor of a USB device would prefer that a different, or xe2x80x9cmore specificxe2x80x9d device driver be used to control the device, rather than the generic device driver supplied by the operating system. For example, a more specific device driver may be preferred to work around known bugs in the device""s software, provide product identification, use value added features, and the like. Such more specific device drivers are typically supplied by OEM/IHV supplied installation media that are distributed with a device. Such installation media include installation disks (e.g., floppy diskettes) or setup computer program applications.
To provide for more specific device driver matches with respect to a USB device, USB device descriptors include markings that describe the manufacturer, product, and revision. An operating system (OS) can use such markings to determine whether a more specific, and therefore a more customized device driver match is available from the installation media. If for some reason a specific match is not found, the concepts of class and subclass codes, as described above, facilitate the loading of a generic device driver to control the device.
Unfortunately, unless the USB DWG has already allocated certain class and subclass codes for a particular USB device, that particular device cannot have a match based on class and subclass codes to identify a generic device driver to control the device. If the device""s corresponding class and subclass codes are not supported by the DWG, an OEM/IHV distributing the device must at least provide installation media with the device to specify a given match that corresponds to a generic driver that is already present on the system. Otherwise, the OEM/IHV must supply a special device driver with the corresponding installation media.
In light of the above, a user of a device that specifies non-standard DWG class codes is required to use such installation media to load a device driver to control the device. It would be beneficial both in terms of simplifying matters for OEMs/IHVs and simplifying customer ease of use if an operating system could specify a default device driver that is already present on the system in response to installing a device that does not specify a standard USB DWG class and/or subclass code.
Ideally, an operating system vendor could develop a new standard USB device classxe2x80x94one not supported by DWG,and distribute a device driver to control devices built to that new standard with the operating system. In this manner, an OEM/IHV could not only distribute devices built to that standard before the USB DWG has adopted a corresponding class and subclass code, but also distribute such devices without needing to supply a special device driver and corresponding installation media. In this way the operating system would natively support the new non-standard USB device by providing a generic device driver to control the new device.
To natively support a non-standard USB device, an operating system would have to request specific information from the new device to identify the new device""s non-standard class and subclass codes to determine the particular generic device driver to control the new device. However, in response to device specific requests from an operating system, a USB device (as currently defined by the USB specifications) can only return information related to vendor identification, product identification, and revision information. There is no standard request to allow a vendor to return additional information to an operating system to indicate that the device supports non-standard class and/or subclass codesxe2x80x94those not supported by the USB DWG.
Thus, it would be beneficial if a USB device could indicate through a predefined USB request that it supports such non-standard class and/or subclass codes. This information could be used by an operating system to install default device drivers to control the USB device. However, as discussed above, such a USB request is not defined by the USB specification.
In yet another example that illustrates the need for a host specific USB request, consider that the DWG has established a number of well-defined requests to obtain interfaces that correspond to functions in certain composite devices. A composite device includes a number of logical devices (LDs), wherein each LD is a fully functional sub-device of the composite device. There is typically a one-to-one correspondence between a function and an interface in a composite device, with the exception of certain devices such as USB speaker devices, which implement more than one interface for a single function. In such exceptional cases, because the DWG has a predefined request to return the multiple interfaces that correspond to a function, each interface can be returned in response to a single request.
Otherwise, when the DWG has not defined such a request, a complex procedure must typically be implemented to determine each of the interfaces that correspond to respective functions in a composite device. For example, to determine if a USB device is a composite device, a host must first request the device to indicate how may functions, or LDs that it supports. In response, a composite device will indicates its ability to support multiple functions by first identifying the number of logical devices (LDs) that the device supports. Next, to obtain specific information corresponding to each supported LD, the host must typically issue separate requests, each request being overloaded with a respective LD identification, to obtain each respective LD descriptor. Thus, a typical composite USB device would not return information corresponding to each interface grouping defined in the composite device in response to a single query unless the single query was already predefined by the DWG to return more than one interface in response to a single request.
It would be beneficial to USB composite device makers and to software developers if there was a simple way for a USB device to specify the interfaces that comprise a single function, such that the interfaces could be determined without the needing to implement the complex procedure discussed above. In this manner, newer composite devices not yet supported by the DWG could be treated exactly as the ones currently supported by the DWG.
Accordingly, the invention arose out of concerns associated with providing a host-specific device request that solves the problems described above.
One embodiment of the described system and procedure specifies non-standard compatible IDs, or non-standard class and subclass codes in a USB device in response to a host-specific device request. A non-standard compatible ID is a class or subclass code that is not supported or defined by the USB DWG. The USB device comprises an extended configuration descriptor in firmware of the USB device. The extended configuration descriptor comprises a set of non-standard class codes that can be used by a host operating system to identify one or more device drivers to control the device. Responsive to receiving a host-specific device request from the operating system, the USB device communicates the extended configuration descriptor to a requestor. Thus, the system and procedure of this implementation simplifies end-user device installation scenarios and allows OEMs/IHVs to implement new USB devices without distributing special device drivers and/or corresponding installation media with each single new USB device.
Moreover, the extended configuration descriptor includes a header section and one or more control function sections. The header section indicates the number of control functions for which mappings exist in the extended configuration descriptor. Each control function section indicates information corresponding to a respective function for the USB device. Each control function comprises one or more interfaces. Because the extended configuration descriptor is communicated to a requestor responsive to the receipt of a single host-specific device request, the inventive concepts of this implementation provide a simple way for a new USB device to specify a group of interfaces that comprise a single function.